LPHOM results for OAEI 2016

This paper presents the results obtained by LPHOM (Linear Program for Holistic Ontology Matching) system in the OAEI 2016 campaign. This is the first participation of our system in the OAEI campaigns. It has participated in four tracks (Benchmark, Anatomy, Conference, and Multifarm). We report here a general discussion on the results and on the future improvements. 1 Presentation of the system LPHOM (Linear Program for Holistic Ontology Matching) is a holistic ontology matching system [2], participating for the first time in the OAEI campaign. Altough the system has been designed to deal with holistic ontology matching [3] (i.e., matching multiple ontologies simultaneously), it is able as well to deal with pairwise ontology mathing, as described here. The reader can refer to [2] for a detailed description of the system. LPHOM treats the ontology matching problem, at schema-level, as a combinatorial optimization problem. The problem is modeled through a linear program extending the maximum-weighted graph matching problem with linear constraints (matching cardinality, structural, and coherence constraints). LPHOM follows the execution workflow as depicted in Figure 1. This workflow is composed of four main steps : 1. The first step consists in ontology loading, flattening and translating. After loading the N different ontologies (two ontologies in the case of OAEI) we flatten every ontology entity (classes, object properties and data properties) in a same structure, named Node. As shown in Figure 1, classes, object properties and data properties inherit from Node. The idea behind flattening the ontologies is to simplify the access to all information about each entity, which can be seen near to the structure of document-oriented NoSql databases. But actually, as duplication and treatment are done in memory, pre-processing is not very performant. This step also includes the translation of the labels of entities in case of the non-English ontologies. For that, we have used the Microsoft-translation Java API1. 2. The second step consists of similarity matrices construction. For a set of N ontologies, we compute N(N − 1)/2 similarity matrices representing the average results of different element-level matchers. These matrices are computed between each pair of ontologies and for each type of entity (classes, object properties and data 1 https://www.microsoft.com/en-us/translator/translatorapi.aspx